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REMARKS/ARGUMENTS 

The present amendment is submitted in accordance with the Revised Amendment 

Format. 

The Examiner has rejected claims 1-3, 5-6, 9-13, 15-16, and 18-20 of this 
Application under 35 U.S.C. § 103(a) as being unpatentable over Sheshadri, "Understanding 
JavaServer Pages Model 2 architecture," published: December 1999, pages 1-140, in view of 
U.S. Patent No. 6,654,932 Bl to Bahrs, and further in view of Prosise, "ASP.NET: Web Forms 
Let You Drag and Drop Your Way to Powerful Apps," pages 1-28. 

The Examiner has rejected claim 4 of this Application under 35 U.S.C. § 103(a) 
as being unpatentable over Sheshadri, in view of Bahrs and Prosise, and in further view of 
Leech, 4GuysFrom Rolla.com, published: December 1, 1999, pages 1-5. 

The Examiner has rejected claim 7 of this Application under 35 U.S.C. § 103(a) 
as being unpatentable over Sheshadri, in view of Bahrs and Prosise, and in further view of U.S. 
Patent No. 6,981,215 Bl to Lindhorst et al. (hereinafter "Lindhorst"). 

The Examiner has rejected claims 8, 14, and 17 of this Application under 35 
U.S.C. § 103(a) as being unpatentable over Sheshadri, in view of Bahrs, Prosise, U.S. Patent No. 
6,453,356 Bl to Sheard et al. (hereinafter "Sheard"), Goodwill, "Pure Java Server Pages," 
published: June 08, 2000, pages 1-4, and in further view of U.S. Patent No. 6,331,187 Bl to 
Jeyaraman. 

Reconsideration and allowance in view of the amendments and remarks is 
respectfully requested. 

Applicant Initiated Examiner Interview 

On December 10, 2008, a telephone interview was conducted between 
Applicants' representative, Lam P. Doan, and Examiner, Wilson W. Tsui. During the interview, 
the references cited by the Examiner in the office action mailed October 15, 2008 were discussed 
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as well as Applicants' claim 1 . The Examiner indicated that the arguments made below will be 
considered when reviewing Applicants' response. 

Rejection under 35 U.S.C. $ 103(a) 

The Examiner rejected claims 1-20 as being unpatentable under 35 U.S.C. § 
103(a) in view of various combinations of cited references. A claim is obvious in view of a 
combination of references if each and every element of the claim is disclosed by at least one of 



Claims 1-3. 5-6. 9-13. 15-16. and 18-20 

The first issue is this case is whether claims 1-3, 5-6, 9-13, 15-16, and 18-20 are 

unpatentable under 35 U.S.C. § 103(a) over Sheshadri, in view of Bahrs, and in further view of 

Prosise. Applicants submit that these claims are not unpatentable because each and every 

element recited in the claims is not disclosed by at least Sheshadri, Bahrs, or Prosise. For 

example, claims 1 provides: 

"A computer program product, tangibly embodied in a machine-readable storage 
device, the computer program product comprising instructions operable to cause 
data processing apparatus to perform operations comprising: 

providing a server-side framework to an application, the server-side 
framework being external to the application, the framework supporting predefined 
data types, each data type having a predefined rule; 

receiving from an application a request for an object, the request 
indicating one of the multiple predefined data types, the object storing a default 
value of the indicated data type, the default value being stored in the object in a 
transfer format and in a process format, the process format being different from 
the transfer format ; 

creating the object in response to the request; 

generating a markup language page that includes the default value in the 
transfer format read from the object; 

sending the markup language page to a browser on a client; 

receiving a user-supplied value in the transfer format from the browser; 

replacing in the object the default value in the transfer format with the 
user-supplied value in the transfer format, the object automatically converting the 
user-supplied value from the transfer format to the process format, the object 
storing the user-supplied value in the process format, the object automatically 
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checking the compliance of the user-supplied value in the process format with the 
predefined rule; and 

if the user-supplied value in the process format complies with the 
predefined rule, forwarding the user-supplied value in the process format from the 
object to the application and otherwise automatically resending the markup 
language page to the browser with the user-supplied value in the transfer format." 

(Claim 1, emphasis added). The Examiner interpreted claim 1 's limitation of "receiving from an 

application a request for an object, the request indicating one of the multiple predefined data 

types, the object storing a default value of the indicated data type, the default value being stored 

in the object in a transfer format and in a process format, the process format being different from 

the transfer format" to be disclosed by a combination of Sheshadri, Bahrs, and Prosise. 

Specifically, the Examiner stated that a combination of Sheshadri and Bahrs discloses the 

limitation "receiving from an application a request for an object, the request indicating one of the 

multiple predefined data types, the object storing a default value of the indicated data type, the 

default value being stored ... in a process format, the process format being different from the 

transfer format." In addition, the Examiner expressly stated that Sheshadri does not disclose the 

limitation "the default value being stored in the object in a transfer format" (i.e. "the object 

storing a default value ... in a transfer format") Furthermore, the Examiner articulated that the 

limitation "the default value being stored in the object in a transfer format" (i.e. "the object 

storing a default value ... in a transfer format") is disclosed by Prosise. 

Applicants respectfully point out that Prosise (or any other cited reference) does 

not disclose claim 1 's limitation of "the object storing a default value ... in a transfer format." 

The Examiner suggests that the following discloses this limitation in Prosise: 

"Because the file in Figure 3 is named MCalc.asp, clicking the button 
submits the form back to itself. This is called a postback. When a postback 
occurs, the input parameters accompanying the request are exposed to ASP scripts 
via the ASP Request object. The script in Figure 3 extracts the user's input from 
the Request object, computes a monthly payment, and then uses the ASP 
Response object to write HTML-formatted results to the output stream. The result 
is shown in Figure 4. The Monthly Payment line at the bottom of the window is 
generated when the script calls the Response object's Write method. That line 
doesn't appear before the Calculate button is clicked because the script won't 
execute the call to Response. Write if the input parameters are null. 
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So far, so good. But if you run the ASP page in Figure 3, you'll find that it 
suffers from one rather severe deficiency: when the postback occurs and a new 
page is returned to the client, the values entered in the text fields disappear. That's 
because the HTML returned from the Web server represents a brand new HTML 
page and ASP does nothing to help controls maintain state across postbacks. To 
fix that, you'll need more code. 

The modified version of the MCalc form (see Figure 5) incorporates the 
input values in the HTML returned to the client so the text fields don't blank out 
when the user clicks the Calculate button. The key is the scripted Value attributes 
added to the <input> tags. When the form is initially displayed, 
Request("Principal"), Request("Rate"), and Request("Months") return null strings 
that result in empty Value fields: 

<input type="text" name="Principal" value=""> 

<input type="text" name-'Rate" value=""> 

<input type="text" name- 'Months" value=""> 
But after the postback, the same expressions evaluate to the strings that the user 
entered, yielding the following HTML: 

<input type="text" name-'Principal" value-' 100000"> 

<input type="text" name-'Rate" value="0.10"> 

<input type="text" name-'Months" value="240"> 
Figure 6 shows the result. Now both the input and output values are visible after 
the Calculate button is clicked, reinforcing the illusion that the user is seeing just 
one page when, in fact, she is seeing two." 



(Prosise, pages 4-6, emphasis added). So, Prosise discloses "[t]he script . . . extracts the user's 
input from the . . . object." Thus, Prosise's disclosure focuses on the user's input (e.g., user- 
supplied values) and an object's interaction (e.g., storing or retrieving) with the user's input. In 
contrast, claim 1 's limitation recites "the object storing a default value ... in a transfer format." 
Since claim 1 distinguishes between a user-supplied value (e.g., the user's input) and a default 
value, and this claim limitation involves the default value , Prosise does not disclose this 
limitation because Prosise's disclosure involves the user's input (e.g., user-supplied values). 



Moreover, the Examiner further explains in the rejection that "the default value is 



null." As understood, the Examiner is suggesting that the "default value is null" is equivalent to 
the "default value" in claim 1 . Accordingly, the Examiner is suggesting that the default value of 
null is being stored web form's input field (see. figure 4 of Prosise). This is reinforced by the 
following disclosure in Prosise: 
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"When the form is initially displayed, Request("Principal"), 
Request("Rate"), and Request("Months") return null strings that result in empty 
Value fields: 

<input type-'text" name-' Principal" value=""> 

<input type="text" name="Rate" value=""> 

<input type="text" name="Months" value="">" 

(Prosise, page 4). Thus, the null value is being stored in the client side (e.g., web browser). 
Applicants' claim 1, however, includes the limitation "providing a server-side framework to an 
application." Therefore, Prosise's disclosure is directed towards storing values on the client side 
whereas Applicant's claim 1 is directed towards storing values on the server side . Since storing 
values on the client side is completely different than storing values on the server-side, Prosise 
does not disclose the limitation "the object storing a default value ... in a transfer format." 

Since claim 1 includes the limitation of "receiving from an application a request 
for an object, the request indicating one of the multiple predefined data types, the object storing a 
default value of the indicated data type, the default value being stored in the object in a transfer 
format and in a process format , the process format being different from the transfer format," and 
none of the cited references disclose "the default value being stored in the object in a transfer 
format and in a process format," claim 1 is not unpatentable under 35 U.S.C. § 103(a) because a 
combination of the cited references fail to disclose each and every limitation recited in the claim. 
For this reason, claim 1 is allowable. 

Claims 2-12 and 19 are dependent claims that includes all the limitations of claim 
1 and includes additional limitations. Therefore, these claims are allowable for at least the same 
or similar reasons as noted above. 

Claim 1 3 is an independent claim that includes similar limitations as the 
limitations of claim 1 . Therefore, this claim is allowable for at least the same or similar reasons 
as noted above. 

Claim 1 6 is an independent claim that includes similar limitations as the 
limitations of claim 1 . Therefore, this claim is allowable for at least the same or similar reasons 
as noted above. 
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Claim 4 

The second issue is this case is whether claim 4 is unpatentable under 35 U.S.C. § 
103(a) over Sheshadri, in view of Bahrs, and in further view of Leech. Claim 4 is a dependent 
claim that includes all the limitations of claim 1 and includes additional limitations. Therefore, 
this claim is allowable for at least the same or similar reasons as noted above. 

Claim 7 

The next issue is this case is whether claim 7 is unpatentable under 35 U.S.C. § 
103(a) over Sheshadri, in view of Bahrs and Prosisc, and in further view Lindhorst. Claim 7 is a 
dependent claim that includes all the limitations of claim 1 and includes additional limitations. 
Therefore, this claim is allowable for at least the same or similar reasons as noted above. 

Claims 8. 14. and 17 

The next issue is this case is whether claims 8, 14, and 17 are unpatentable under 
35 U.S.C. § 103(a) over over Sheshadri, in view of Bahrs, Prosise, Sheard, Goodwill, and in 
further view of Jeyaraman. 

Claim 8 is a dependent claim that includes all the limitations of claim 1 and 
includes additional limitations. Therefore, this claim is allowable for at least the same or similar 
reasons as noted above. 

Claim 14 is a dependent claim that includes all the limitations of claim 13 and 
includes additional limitations. Therefore, this claim is allowable for at least the same or similar 
reasons as noted above. 

Claim 17 is a dependent claim that includes all the limitations of claim 16 and 
includes additional limitations. Therefore, this claim is allowable for at least the same or similar 
reasons as noted above. 

Applicants respectfully submit that this rejection has been overcome. 
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CONCLUSION 

In view of the foregoing, Applicants believe all claims now pending in this 
Application are in condition for allowance. The issuance of a formal Notice of Allowance at an 
early date is respectfully requested. 

If the Examiner believes a telephone conference would expedite prosecution of 
this application, please telephone the undersigned at 408-244-6319. 

Respectfully submitted, 

/Lam P. Doan.Reg#63593/ 

Lam P. Doan 
Reg. No. 63,593 

FOUNTAINHEAD LAW GROUP P.C. 
900 Lafayette Street, Suite 509 
Santa Clara, CA 95050 
Tel: 408-244-6319 
CRW 



Page 13 of 13 



